The present invention relates to computer implemented processes and systems including software, and in particular, to systems and methods for freezing data.
Organizations have always had a need to monitor their business activities. In the wake of financial scandals like Enron and the enactment of Sarbanes-Oxley, organizations have increasingly turned to governance, risk management, and compliance (GRC) and separation of duties principles to manage and regulate their business activities. Generally, the organizations use these concepts to detect, prevent, and remedy fraud, crime, and other illicit behavior that may occur within an organization.
Generally, many actions (i.e., transactions or tasks) can be performed on an enterprise system. For example, possible actions include creating a vendor, paying a vendor, creating a user, approving a document, or making changes to data. To make changes to data, the data may need to be accessed in order to perform an action. To control risk in an organization, many software systems may freeze data after a particular individual in the system officially signs-off on the data (i.e., certifies that the data is accurate and compliant). Once data is frozen, it may not be changed within the system by other users. However, GRC extends to systems and processes based on rules not derived from law or regulation. For example, governance rules for a business may reflect the way a business wishes to operate.
For example, historic data may never be changed after administration officers (e.g., CEO, CEO, etc) have signed-off Sign-off is an action done by CEO/CFO to confirm the financial report, internal control records, or the like, are correct. Once data is frozen, users of the system may only have a read-only access on the frozen data. The data is frozen (or locked) to prevent any further changes.
There are currently two well known methods for preventing changes to signed-off data. First, the data may be archived. For instance, after an officer signs-off, the data can be archived immediately (e.g., in a separate data storage repository). Typically, a background job is triggered for large data sets to move the data from a local system to an archive system. In some instances, a business warehouse (BW) application may be used to perform analysis on the historical data. One problems associated with this approach is that archiving can be time consuming and data processing intensive. Since archiving takes time, the system may need to be inaccessible to users for several minutes, hours, or even days depending on the data volume and system hardware performance. To prevent any change during archiving, user login may need to be blocked during the archiving period. Additionally, once the data is archived, it becomes more difficult to access the data by one or more applications such as an Enterprise Application. Further, in many situations it is desirable to reuse commonly used data after it is frozen for other purposes. For instance, at the end of a fiscal year, an archive system may archive a previous year's data, but may be required to create new data objects for the next year with the same data, which may change, rather than reusing the existing data objects from the previous year.
Yet another approach to freezing data is flagging. Using this approach, each data object in the system that is to be frozen includes an extra flag attribute to indicate that the data object is frozen. Flagging does allow for the frozen data to be available sooner than archiving. However, flagging each data object individually can also be programmatically and computationally inefficient. Further, as with archiving, once a data object is flagged, the data is frozen and it may be difficult or impossible to reuse the data objects.
Therefore, it would be desirable to have a technique for freezing data that overcomes the problems above and others.